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(57) ABSTI^CT 

A workflow processing framework provides common 
objects and business processes for the creation of an 
enterprise- wide workflow processing system. Conventional 
workflow, database and other platforms are accessed using 
standardized protocols. The use of common objects provid- 
ing robust functionality while being insulated from the 
specific platforms used to implement the workflow process- 
ing system enable the common objects to be reused to 
perform many functions in many different lines of business 
without modification. If necessary, foundation objects are 
written to utilize the existing platforms more fully than 
permitted by standardized protocols. The business processes 
are generalized as much as possible, but are customized as 
required to fit the enterprise environment. 
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DEVELOPMENT FRAMEWORK FOR CASE 
AND WORKFLOW SYSTEMS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is directed to automated workflow 
systems and more particularly, to an object-oriented frame- 
work used in developing and implementing consistent work- 
flow systems in a single department or throughout an 
enterprise, such as a corporation or a government agency. 

2. Description of the Related Art 

Computer programs have been written for businesses 
since the 1950' s and 1960*s using first machine code, then 
assembly languages, COBOL, and third, fourth and fifth 
generation languages. Most work in oflSces uses at least one 
and often several computer programs, including languages 
and software tools that are used in many different industries, 
such as word processing, spreadsheets, databases, etc., to 
industry-specific or line-of-business programs, many of 
which are used to manage the work performed in a specific 
industry or within certain parts of an industry. In the 1980's, 
imaging began to be used to support line-of-business 
programs, reducing the amount of paper required to perform 
the business functions by storing the paper image in the 
computer as part of the business program. In the late 1980's, 
companies such as FILENET, IBM, WANG, etc., developed 
workflow products of various types. At first, workflow 
processing products were added to imaging systems in an 
effort further the "paperless oflfice". Workflow was attached 
to image-enabled systems because the presence of the elec- 
tronic image (as opposed to the paper document) allowed the 
workflow system to "push" work to users in addition to 
using "puU" technology. With an electronic image, the 
image could be presented to the user when the work was 
pushed to them; if paper was required, pushing work to an 
individual required that the individual then physically 
retrieve the paper when the work item was pushed to them. 
Workflow systems developed along several dimensions: 
"collaborative workflow** was developed to support ad hoc 
workflow requirements — where the knowledge worker 
developed a workflow based on the characteristics of each 
business case; "embedded workflow** was developed to 
support simple workflow requirements that are a required 
part of business systems; and "mission critical" workflow 
was developed to support high volume, predictive work- 
flows. 

Management of "mission critical" woric in an organization 
requires significanfly more than the features provided by 
embedded and collaborative workflow systems. A type of 
workflow processing system termed "utQit/* systems com- 
bine complex process rules stored in a database, existing 
system interfaces, and user interfaces that control what is 
available to a worker at a computer workstation or terminal, 
and may monitor the work being performed. 

Three types of utility workflow processing products have 
evolved. The first products that were commercially available 
were development languages developed to support work- 
flow. Instead of using general development languages (e.g., 
COBOL, BASIC, FORTRAN), these workflow languages 
were developed to facilitate the programming of work 
processes, much as specialized development languages were 
developed for such functions as artificial intelligence (e.g., 
LISP) and process manufacturing. Examples of these "gen- 
eral purpose" workflow languages include FILENET'S 
VISUAL WORKFLO, IBM's FLOWMARK, and STAFF- 
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WARE'S STAFFWARE. Some of these products support a 
wide range of capabilities and functions for the enterprise, 
some are focused on a smaller set of functions and smaller 
user implementations. 

5 The other two types of utility workflow that have evolved 
include workflow that is specific to a line-of-business or 
apphcation and workflow that has been added to a suite of 
business applications. Examples of the former include tem- 
plates for various financial applications from 

10 PEGASYSTEM, mutual fund applications from DST 
SYSTEMS, Inc. and BANCTEC'S PLEXUS-applicatioos 
for the financial services industry. In these applications, 
business specific workflow rules and processes are provided 
as a full or partial solution (often referred to, respectively, as 

15 a package or a template). Some of these solutions are built 
using general purpose workflow development languages, 
some have been built using custom workflow languages. The 
workflow supported by this class of systems is typicaUy 
hardcoded (necessitating coding changes to programs writ- 

20 ten in general purpose programming or workflow languages 
when changes are required) and supports only the specific 
workflow functionality required by the application. 
However, even if the workflows are offered for a range of 
business functions, they do not utilize the same process 

25 definitions and code; at best they reuse the code, at worst the 
code is unique for the line of business. 

Examples of the third type of workflow solution include 
financial and enterprise resotirce planning (ERP) suites such 
as those from ORACLE, BMN, and SYSTEMS, 

30 APPUCATIONS. AND PRODUCTS in Data Processing 
(SAP). These application suites often share data and func- 
tions across the lines of business, but only support rudimen- 
tary workflow functions and should not be characterized as 
mission critical workflow. They are included in this category 

35 only because they arc marketed as mission critical solutions. 
The state of the art is that there are powerful workflow 
toolsets that require specific products to support their use 
and enable a user to create a customized worMow process- 
ing system with significant effort. There are also many 

40 products designed for specific applications within an indus- 
try that can be customized with varying amounts of effort. 
Examples in the claims processing area include QUICK 
START for Data Entry from AMERICAN MANAGEMENT 
SYSTEMS and similar products from IPD, IMAGE 

45 MATRIX, and others. 

However, there are no scalable products designed to 
provide standardized workflow processes in a department or 
throughout an enterprise, that are applicable across indus- 
tries; provide the coding efficiency of object-oriented 

50 design; and utilize open standards to work with existing 
third party tools and languages, such as databases, graphical 
user interface languages, etc., currently in use or desired to 
be used by the organization implementing the workflow 
processing system. 

SUMMARY OF THE INVENTION 

wiwfckl jUis ^rij Dbiect of the present invention to provide a 
ME^me y^ j^g f^p^ 

uang.ot?jm^^eMd?^esig^ 
50 ^ffiit*aind-maintenance-.requirements.in,impJcmentation,iQ 

individual departments and ^throughout an eniErprise.^ 
It is anotheBobjea^of^the^prie^jinnvention to provide a 

wohE fio:w^i)gogpssing fi'atne work utiUSng^existing^third 

par ty tools , and languages tfirough™adhecence«lOjiStan^ds 
65 andfanyopeflSarchiiecture^^ -. 

It is a further object of the present invention to provide a 

workflow processing framework that enables users to define 
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logical queues ihrougb dynamic work divisions without able products are generally proprietary in nature, i.e., they 
requiring coding changes to programs written in program- are easQy used only with products from the same vendor or 
ming languages. :,. a small number of third party vendors or in specific lines- 
It is a yet furthe) object of the present invention to provide of-business. The remaining products were designed with 
a workflow processings framework that can operate on fold- 5 such a narrow focus that the products cannot easily be scaled 
ers containing any type of data accessible in electronic form ^ serve a variety of types of workflow processing, 
and prefetch the data without requiring knowledge of how to The three-dimensional drawing in FIG. 1 provides an 
access and utilize the specific type of data by the user illustration of how limited prior art workflow processing 
defining what is included in a folder. systems are compared to the present invention. Along the 
The above objects can be attained by a workflow pro- horizontal axis are examples of four different workflow 
cessing framework, scalable for use by a single department processing systems that have been developed for the insur- 
to an entire enterprise, including a set of softw^rtf objects, ^nce industry. The illustrated examples of "line of business" 
each unique throughout thg pfcQteH )iiise;*togsupi)ot^^ functions, arc processing of insurance claims, new business 
spondingJ&usiaessJ&fnctiQcSige^ i underwriting, customer service and annuity processing. 
febs^&t^ofeaidj y^ ^^ P Examples in other industries are credit card fraud 
~ rk steps iSw'S^^pfo^ssmgran^ a workll™"engme processing, credit application processing, medical records 
?SfiMhg'^id'%ftware-objects''affd*niiS*^ dispute processing, etc. Illustrated along the 
i^forimthe^a^origow processing. JTh axis are some of the functions typically performed 
ffimework can be used to develop a^rkflow processing *>y these existing systems: routing, workload balancing, and 
system by entering data into the database to define work quality assurance. 

types and work steps for workflow processing, creating a As in the case of "line of business*' products, the prior art 

graphical userr interface (GUI) to use the set of objects, and includes cross- functional workflow processing systems like 

defining the workflow in the workflow engine. those arranged along the vertical axis. Generic accounts 

These together with other objects and advantages which payable systems are available in the form of templates from 
will be subsequently, apparent, reside in the details of Unisys and Crowe Chisek. Similarly, workflow processing 
construction and operation as more fully hereinafter systems capable of being used for call centers are available 
described and claimed, reference being had to the accom- fro™ Pegasystems and Mosaix as well and routing products 
panying drawings forming a part hereof, wherein like are available from middleware vendors such as Hewlett- 
numerals refer to like parts throughout. Packard and Early Cloud (now owned by IBM). 

lypicaUy, the data operated on by workflow processing 

BRIEF. DESCRIPTION OF THE DRAWINGS systems is determined when the workflow processing system 

FIG. 1 is a threcKiimensional illustration of types of ^ designed and is limited to a few types, such as database 

applications, types of functions performed in each applica- records, electronic documents, e.g., word processing 

tioD and information used in carrying out those fimctions in 35 documents, and images, such as TIFF Uvel 4, GIF, JPEG, 

a workflow processing system. ^t^. for images, CAD drawings, medical X-rays, etc. As 

rnr- -j • „ • described below, the present invention is designed to handle 

HO. z IS an overview 01 the appucation program code in „ . , , . « 1 . 

i rt * J' * *i_ * all known data types and is flexible enoueh to add additional 
a workflow processmg system according to the present , , , , 7 v^v^^gu ^ ««« auwin^uai 
invention ^ r data types with mmmial changes to the framework of objects 
^ . . An ^sed by the present invention, 
FIG. 3 IS a more detailed block diagram of the obi ects and • • - , , , 
business processes in a workflow processing framework ^^^^^^f P"<^^^ %f^^^ mapped onto the three- 
according to the present invention. dimensional drawing lUustrated in FIG. 1, the systems 
r^^o AAA^ t.* r.. . woiUd use only two dimensions and fill a small amount of 
HGS. 4A-4C are a hierarchical diagram of objects m a ^^^^ ^^^^ dimensions. For example, an insurance claims 
workflow processing framework accordmg to the present workflow processing system would include the fiinctions of 
mvcntiOD. automated work distribution, document rendezvous, work 
HG. 5 is a flow diagram of events processing and queue step division, and letter generation. Similarly, an accounts 
assignment in a workflow processing system according to payable system might be limited to electronic documents 
the present invention. and images of the types of data illustrated in FIG. 1, 
RG. 6 is a flowchart iUustrating an example of workflow 59 depending upon how it is designed, but would be imlikely to 
processing according to the present invention. include data records, audio or video. 

FIG. 7 is a block diagram of a workflow processing The present invention uses a set of software objects, each 

system according to the present invention. uniquely performing a corresponding function in a workflow 

processing system and a set of process definitions, accessed 

55 by a subset of the software objects, to provide a flexible 
workflow processing system that can be expanded in any of 

There are several drawbacks in the state of the art of the three directions illustrated in FIG. 1, The software 

workflow processing development systems. Existing objects are designed to be generic and provide robust 

toolsets can be used to generate many types of systems, but functionality. Tables are used to specify the functions per- 

the effort required for an entire enterprise would be only a 60 formed by the objects. This design enables the framework to 

slight improvement over using general purpose program- be expanded easily in any of the three directions illustrated 

ming languages from scratch since many workflow func- in FIG. 1. Objects in the core are suflBciently generic so that 

tions would need to be built for each and every individual they can be used in workflow processing systems for any 

application. Existing template products are similarly line of business that can be mapped to a case paradigm. The 

designed for smaU-scale applications and are not powerful 65 functionality provided by the objects is broad enough to 

enough to serve a variety of workflow processing applica- apply to many different line-of-business functions, including 

tions throughout an enterprise. Many of the currendy avail- the three horizontal applications illustrated in FIG. 1, as well 
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as child welfare case processing, telephone bill presentment 
processing, health claims processing, dispute processing, 
fraud recovery processing, new application processing, 
return mail processing, and many more. Additional pro- 
cesses are written around the core of objects to customize a 5 
workflow processing system for a specific enterprise 
environment, as discussed with respect to FIG. 2. 

The relationship between the objects in a workflow pro- 
cessing framework according to the present invention and 
the peripheral processes is illustrated in FIG. 2. At the 
bottom level are conventional platforms 20. Examples of 
platforms that may be used to support workflow processing 
include a workflow engine, like FileNET Visual WorkFlo, 
development languages, databases or data warehouses, 
existing imaging systems, existing systems of record, etc. 
These conventional platforms 20 may run on any type of 
computer system that has communication capability, includ- 
ing Windows, UNIX, or any mainframe operating system. A 
set of foundation objects 22 access the conventional plat- 
forms 20 using standardized protocols whenever possible. 
For example, the framework preferably uses Distributed 20 
Component Object Model (COM/DCOM) in a Microsoft 
Windows 32-bit operating system to communicate with the 
workflow and imaging engines using FileNET Panagon and 
databases using ActiveX Data Objects (ADO). DCOM 
enables the workflow processing system to create and inter- 25 
act with software objects on separate computers in a pro- 
gramming language neutral and operating system neutral 
manner. 

The foundation objects 22 are illustrated separately from 
the objects 24 providing common functions in support of 30 
different applications, because in a specific enterprise envi- 
ronment standardized protocols may not be available and the 
foundation objects may need to be modified to utilize 
conventional platforms 20 existing in the enterprise envi- 
ronment or previously selected for use with the workflow 35 
processing system. For example, in the exemplary embodi- 
ment of the present invention described below, FileNET 
Visual WorkFlo is used as the workflow platform included in 
conventional platforms 20. However, only the foundation 
objects 22 have to be changed to accommodate the use of a 40 
different workflow platform. 

The objects 24 providing common functions in support of 
different applications provide "foldering" of materials (such 
as electronic documents, images, data records, etc.) used by 
each case and workflow function, including folder 45 
manipulation, rules based folder queuing and subsequent 
retrieval, distribution, event triggering, etc. Business- pro- 
cesses 26 written in conventional programming languages 
perform enterprise specific functions. The business pro- 
cesses 26 may be written in a variety of programming 50 
languages, such as Microsoft Visual C++, Microsoft Visual 
Basic, Sybase PowerBuilder, or Active Server Pages (ASP). 
A graphical user interface (GUI) is included in the business 
processes 26, so that a human worker using the workflow 
processing system is presented with a computer desktop 55 
display consistent with other programs in use at the enter- 
prise. Business processes 26 preferably include modules that 
can be reused in many enterprises with very fittle customi- 
zation. The use of tables, as described below, minimizes the 
amoimt of customization of many of the business processes 60 
26. The architecmre illustrated in FIG. 2 is used to suppo^^' 
different applications. Different applications and different 
users would utilize different subsets of the business pro- 
cesses 26, common objects 24, foundation objects 22 and 
conventional platforms 20. 65 

Common objects 24 and business processes 26 are illus- 
trated in more detail in FIGS. 3 and 4A-4C. A hierarchical 



diagram showing the relationship of the common objeas 24 
and foundation objects 22 is provided in FIGS. 4A-4C. FIG. 
3 provides an overview of common objects 24 and business 
processes 26. In the preferred embodiment, the workflow 
processing framework uses the case paradigm and thus, the 
first three objects in the middle row are Case Session, Case, 
Case Item and Case Worklist. As described below, with 
reference to FIGS. 4A and 4B, Case Item is preferably 
included in the Case class, but is such an important object 
that it is included in FIG. 3. Other common objects include 
Security, Expression Evaluator, Error Logging, Debug 
Logging, Statistics Logging, and DataBase Connector. 
Foundation objects 22 that are productA^eodor specific are 
called by some of these objects, such as Database Connector 
and possibly Error Logging if there are standards set by the 
enterprise for how errors are handled. The common objects 
are described below in more detail with respect to FIGS. 
4A-4C. 

Business processes 26 are preferably C++ modules that 
may need to be modified in a specific enterprise environ- 
ment. Starting on the right of the top row in FIG. 3, the 
Graphical User Interface will almost always be further 
developed when a workflow processing system according to 
the present invention is implemented, so that the user 
interface is customized for the specific enterprise environ- 
ment. As described below in the example illustrated in FIG. 
6, the remaining business processes 26 use tables to mini- 
mize the amount of customization required, but may require, 
modification depending upon the type of information and 
how the information is handled. These tables essentially 
contain rules on how the data is handled and thus, the Queue 
Assignment module can be considered specific implemen- 
tations of a rules processor. The Case Builder module 
embodies specific business rules through customization. The 
Events Processor module matches incoming events with 
pending events by comparing event code values customized 
for each business. The User Assignment module provides 
balanced distribution of work based on each user's load 
factor stored in a database table. 

The following description of these business processes is 
-done in context of a typical workflow system. The Case 
-•Builder is used to determine either when to create a new case 
or when and how to rendezvous an incoming document with 
an existing case folder. The Events Processor, on the other 
hand is executed whenever an event occurs that requires a 
change in workflow. An event can be any change by a 
worker (user of the workflow processing system) or system 
module, or the expiration of a timer. The Events Processor 
is scheduled at intervals throughout the workflow. One of the 
events that the Events Processor executes is the creation of 
a new case from Case Builder. After the Events ftocessor 
has determined the reason for moving the case folder 
through the workflow, Queue Assignment is executed to 
determine in which work step division the case should be 
processed. Finally, if the workflow processing system 
requires that the determined work step division should have 
users assigned to the cases, the User Assignment module is 
executed. 

As illustrated in FIGS. 4A-4C, most of the common 
objects 24 are collected in a parent object BLCaseSession 
60. The two basic fimctions performed by the common 
objects are GetFilteredWork-List, GetUserWorkList and 
GetCase which results in the creation of BLCaseWorkList 
62 and BLCase 64 objects. The other objects at the same 
level as BLCaseSession 60 include BLDBCoimMgr 66 
which provides access to databases in the conventional 
platforms 20 as required by the objects in BLCaseSession 



08/26/2003, EAST Version: 1.04.0000 



us 6,606,740 Bl 
7 8 

60. The object BLConfigParam 68 provides an interface keeps track of the current and next case objects using 
with the operating system configuration information. In the semaphores, threads, and class member variables. The con- 
preferred embodiment, BLConfigParam 68 accesses the sumcr thread is the normal user thread of BLCaseWorkList 
Windows Registry to obtain parameters used by the work- ^2, From the consumer thread the current case is obtained 
flow processing system. Next are three objects that perform 5 ^om the list. The producer thread executes as long as 
logging for debugging, error handling and statistics; BLDe- BLCaseWorkList 62 exists in memory. Whenever the next 
bugLog 70, BLErrorLog 72 and BLStalLog 74. case object is I>rULL, the producer thread retrieves the next 
T" 7 ^ , , , . . „ available case from the database. Whenever the next case 
Of the final two top-level comnaon objects, BLProgram- ^^-^^ ^^^^ ^^^^^^^^ ^^^^ ^^^^ ^^^^^^ 

Security 76 and BLCorelnstMgr 78, the first performs an ^^^^^ retrieved into processing by the 

miportant function m workflow processing and the second is consumer thread 

used to manage instances of ejects that are "Mted by the whenever a case is retrieved from the database platform 

workflow processing system. BLPiogamSecunty 76 deter- ^ conventional platforms 20, a prefetch of that case is 
mmes the access of an individual user or group ofusers to j,,^, ,^,^1, ^as an enumerated type 

fiinctions withm the workflow processmg system. There are ^^j^j^ ^^^^ ^ determine what components of 

three levels of secunty. Tlie first type of secunty k Uie the case need to be prefetched. TTie enumerated type allows 
application with which the user ^ permitted to work For gj^^^ ^^^^ 

example, a typical worker may only use the insurance Claim • -j, n • r . u *• tu- 

I - -It J- I. 1 u J 1 ri-T^ t component type individually m the prefetch operation. This 
application illustrated m the left hand column of FIG. 1, or r » u «i. i • . "j • i i- . . 

... ■ • .1 cAr^ prefetch filter value is set dunng workhst construction as 

the loan applications processmg in the next column 01 rIO. » c *i. * • i . i 

1 b k) h ^ system implementation. For example, a system 

' * implementer can choose to have the case documents and the 

The second type of security is the task of the user, e.g., ^ase audits prefetched, but not the case events. This enables 
process claim 1, process claim 2. The second type of security prefetch requirements to be tailored to the environment 

is typically used in a situation where a single user interface ^^ch specific implementation. 

is created that operates in different modes. In this situation ^^^^^^ ^ determined based on user identification 

although there are different work steps in the workflow, a ^^^^^^^ ^^^^ ^^^^^^ computer system on 

smgle user interface may be used as the work step busmess ^^^^ workflow processing system is running, BLCase- 

application, with its configuration changed for each differen WorkList 62 calls a coUection of objects named BLWF- 

mode of operation The tasks are defined m the tables WorkListFields 80 formed of objects each named BLWF- 

descnbed later and are identified m a user record. An WorkListPield 82. An object is called by 

example of a user record is provided mimediately below. BLWFWorkListField 82 to access the workflow engine. The 

object used will depend on the workflow engine included in 

the conventional platforms 20. In the example iUustrated in 

BI^USEEIPROFILE FIGS, 4A-4C, VWOWorkQuery 83 accesses the \^sual 
SUSERID = juscr 35 WoikFlo to obtain information in the workflow platform 

.^^fJ^^xf, Z identifying the fields used by a case, such as the name of the 

worker, the case number, the case type, the event that caused 



BISAVAEABLE - Y 



BL_PROGRAMSECURrry , , , o . . 

SUSEEUD - juser the case to enter the workflow, the dollar amount, etc. 



SPROGRAMNAME = Claim E*roccssiag Once a worklist has been obtained, the user can select one 

^t^-TASKSECURiTY ^jjg ^ases on which to work. The GetCase function is 

sprogS^aiiI^e- Claim Processing called by BlCase Session and renims an object caUed 

STASKNAME - Claimi BLCasc 64. The BLCase object 64 contains several coUec- 

BL^FUNcnoNSECURTTY tions of objects to obtain the case information. BLCase- 

susERiD = juser Fields 84 is a collection of objects containing the informa- 

SPROGRAMNAME - Claim Processing ^ c i_* - j £^ *u j * 1. 1 *r 

CTASKNAME = Claimi * ^^^^ obtamed from the database platform m 

SFUNcnoNNAME - Write Custom Letter conventional platforms 20, For example, the information 

for: an insurance claim may include case identification 

number, incident number, date of incident, name of insured, 

The third level of security is the function within the task. ^laim doUar amount, type of claim, etc. BLWFWorkltem- 

For example, while a function such as Write Custom Utter pi^i^s is ^ coUection of objects containing information 

may be included in an insurance claim appUcation, only identifying where the case is in the workflow. The informa- 

certain users might be aUowed to access this function. Other ^ BLWFWorkltemFields 88 is obtained from the woric- 

workers would be limited to ordinary correspondence pro- fl^^ platform in conventional platforms 20, 

cessing and customer service functions iUustrated in FIG. 1, BLCaseEvents 92 is a coUection of objects containing 

and perhaps additional fonctions not iUustrated. information regarding events that have or will occur during 

BLCaseWorkList 62 retrieves a prioritized worklist for a the existence of a case. The events are defined during each 

user when a worker starts a session with a workflow pro- system implementation. For example, the receipt of a docu- 

ccssing system according to the present invention. The next ment in a case, the creation of a new case, and the expiration 

case can be retrieved while simultaneously processing the of an event tied to a time period may be defined as events in 

current case by user interaction through a cUent/servcr GUI a system. Each system implementation is aUowed to create 

envinDnmcnt. Ordinarily a user wiU require a few minutes to its own events by writing an event code to the 

process the work item. During that interval BLCasc- BL_CaseEvent table by using BLCase.AddPendingEvent 

WorkList prefetches the next case to the client workstation or BLCase.AddReceivedEvent. The Events Processor does 

of the user. This limits Uie idle time of employees between not need to be modified when new event codes are added, 
and during cases and increases the output of the employee. ^5 xhe received event codes are matched with the pending 

BLCaseWorkList 62 is a multi-threaded COM object that event codes by the Events Processor. As long as the pro- 
operates in a producer-consumer environment. This object grams writing the event code to the Events Processor are 
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synchronized such that the program writing the pending and received "Signature Document" event codes and trig- 
event writes the same event code as the program writing the gers the work object to the user for review, 
received event, the Events Processor wiU recognize and Preferably graphical user interfaces (GUIs) in a general 
process the events. The information contained in BLCa- purpose language like Visual Basic are included in a work- 
seEvents 92 is obtained from the database platform in 5 flow processing system according to the present invention to 
conventional platforms 20, in a manner simUar to that used provide programmers with the bulk of the code necessary to 
by BLCaseFields 84. implement modules like those described above. Examples 
The next two objects illustrated in FIGS. 4A-4C are items are Scan, Index, System Maintenance, Case Retrieval, and 
in a case folder. BLCaseltems 96 represents items that will Document Retrieval interfaces. 

not have different versions. In the preferred embodiment lo After incoming documents are prepared for input and 
optical storage is used for the data and each BLCaseltem 98 sorted into appropriate batches, operators scan documents in 
obtains the information by accessing the optical storage by batches into the imaging system. The Scan interface pro- 
calling an imaging system object specifically for the type of vides a processing window that requires users to enter 
optical storage unit used in the system. BLDraftCaseltems information specific to the current batch. The user also has 
100 are documents related to the case that are in process of 15 abihty to set properties of the scanner. When the man- 
being created and for which there may be different versions datory information is entered and the user is satisfied with 
that do not need to be saved on optical storage until the final the settings, the scan processing window allows the user to 
product has been determined. The information in each start and stop the actual scanning process. 
BLDraftC^eltem 102 is obtained from the conventional j^^ex interface provides the ability to assign data 
platforms 20 usmg the BLCase Object. BLDraftCaseFields 20 ^^^^^ ^ docmnent for fixture retrieval. The Scan process 
104 are die data values stored with a BLDraftCaseltem 102 dispatches batches to an Index and Reassembly process, 
when the item becomes permanent. ^ ^^^^ ^^^^^ Reassembly process, the 

In addition to calling the objects illustrated in FIGS. process retrieves a user work list for that user and the 

4A-4C, BLCase 64 also uses several methods to perform divisions within the Index and Reassembly work step. The 

operations itself. BLCase AddNewItem and BLCase.Add- process loads the first batch in the user's work list onto the 

NewDraftltem are used to create a new BLCaseltem 98 and index and Reassembly window. The process loads the first 

a new BLDraftCaseltem 102, respectively. BLCase- document of the batch into the image viewer and the 

WorkList.Prefetch performs the prefetch operations document is ready for indexing. The actual index fields 

described above. BLCase. AddPendingEvent and displayed for indexing is based on the document class and 

BLCase.AddReceivedEvent are used to create events, as varies widely with each system implementation. Therefore, 

described below. the Index process does not implement the index values 

BLCaseAuditSessions 108 are a collection of objects used control which may, for example, be an Active X control 
to keep track of work performed on a case during the developed by the organization that uses the workflow pro- 
sessions on which the case is worked. BLCaseAudits 112 are cessing system. When a user finishes indexing the 
a collection of objects containing information about the document, he/she clicks the index button. The Index process 
actions taken during a session. What information is stored in saves the index values for the current document and loads 
each BLCase Audit 114 can be determined when the work- the next document that has not been indexed, 
flow processing system is implemented. The Index and Reassembly process aUows for the reas- 

The workflow platform in the conventional platforms 20 40' sembly of docimaents in parallel with the indexing of docu- 
includes a definition of what information will be captured by ments. When reassembling documents within a batch, the 
BLCaseAudits 112. In the Visual WorkFlo system used in user may have the ability to add documents, delete document 
the exemplary embodiment, the definition of what informa- separators, mark documents for rescan, move pages, copy 
tion will be stored in BLCaseAudits 112 is determined by pages, and paste pages. These capabilities are easily pro- 
each individual system implementation, BLCase Audit 114 45 vided when, for example, Visual WorkFlo is used as the 
defines the interface to write the audits. Each business workflow engine. The user can view the structure of the 
application must define and write its own data to the audit batch in the batch reassembly tree to determine whether or 
log. not to take these reassembly actions. For example, some fax 

As an example, a user can suspend a case awaiting a transmissions are received as one transmission but contain 

signature document using a module like the Case Manager 50 several documents. There is no exact method to determine 

described below with reference to FIG. 6. The Case Manager ^® document breaks within a single transmission. The 

module calls the BLCase.AddPendingEvent method with indexer reviews each batch and adds new documents as 

the parameters (EventCode-"ADD_DOC_SIGNArURE_ necessary. The indexer can then move pages into the newly 

DOC", EventDescription-"Signature Document", Expire- created documents. 

"current date+10 days", GroupID-"", GroupEventCode-"", 55 When the user indexes all documents in the current batch, 

OptionalEventData-""). This adds a record to the the process prompts the user to commit the batch. If the user 

BL_CaseEvent table that indicates that the case is waiting chooses to commit the batch, then the process commits the 

for a signature document to be received within 10 days or it batch and loads the next batch in the user's work list. If the 

will be triggered to the user for review. When the document ^ser chooses not to commit the batch, the user is allowed to 

is received, the Case Builder module calls the BLCase .Ad- 60 continue re-indexing documents or rcasscmbhng the batch 

dReceivedEvent method with the parameters (EventCode- the user is ready to commit via the commit batch menu 

"ADD_DOC_SIGNATURE„DOC", EventDescription- option. 

"Signature Document", Received -"current date". The System Maintenance interface is a program that is 

CaseItemName-"Doc ID", OptionalEventData-""). This customized for each system implementation. While some of 

adds a record to the BL_Case Event table that indicates that 65 the code is very specific to an implementation, e.g., specific 

the case received a signature document. The next time the edit checks, some things remain the same. There is always 

Events Processor module mns, it matches up the pending a set of baseline tables that have a constant table structure - 
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and there is a framework for selecting and displaying table 
information. Therefore code for these functions is preferably 
provided by a workflow processing system according to the 
present invention. 

The System Maintenance interface has two basic screens. 
The first is the main window, which has a picture list-box 
down the left-hand side and a grid control covering the 
remainder of the window. The window creates itself dynami- 
cally from a set of constant data structures which lists the 
icon to be shown in the picture list-box as well as the fields 
in the corresponding table to be show in the grid for that 
selection. The second window is a sample property-tabbed 
dialog that the user uses to update any of the values from the 
grid. No data is actually modified in the grid. BLErrorLog 
72, CNativeErrorLog (not shown), BLStatLog 74, BLDe- 
bugLog 70, CNativeDebugLog (not shown), BLDBCon- 
nMgr 66 and BLProgramSecurity 76 are used. 

Document Retrieval is also a commonly requested inter- 
face. Although the actual window that users view from 
implementation to implementation differs, the basics of 
creating and executing a query against the imaging platform 
in the conventional platforms 20 are very similar. A work- 
flow processing system according to the present invention 
preferably provides a program that implements the basics of 
taking a query and executing it against the imaging platform 
in the conventional platforms 20. 

Document Retrieval (and Case Retrieval) preferably use 
conventional protocols of the operating system for selecting 
files. An interface is preferably included in the basic work- 
flow processing system to provide a simple search criteria 
window. When the user clicks Search, the program prefer- 30 
ably uses the workflow engine in the conventional platforms 
20, e.g., FileNET*s OLEDB provider to retrieve a list of 
documents using an ADODB.RecordSet object 118 (FIG. 
4A). The contents of the record set will fill the expanded 
window with a grid of document indices. Users may then 35 
select a document and view it in the workflow engine's 
native viewer interface. 

Document Retrieval will make full use of the 
BLErrorLog, CNativeErrorLog, BLStatLog, BLDebugLog, 
CNativeDebugLog, BLDBConnMgr and BLProgramSecu- 40 
rity objects. The majority of the code will be implemented 
in a COM object to allow other programs to include Docu- 
ment Retrieval capabilities within their operations. 

Although Case Retrieval has slightly more variation from 
one system implementation to another than Document 45 
Retrieval, the basics are still the same. The window in Case 
Retrieval will look very similar to Document Retrieval. 
There wfll be a simple search criteria window allowing the 
user to enter specific case data values. After clicking search, 
the main window will expand to show a grid with case data 
for any matching cases. 

The Index, Document Retrieval, and Case Retrieval inter- 
faces are implemented with common functions and features 
and may be implemented with a basic interface control that 
provides sample search data capabilities. Each specific 
implementation modifies this interface control without 
changing the rest of the application or re -compiling the 
application. 

The GUI can be thought of as a standalone program, a 
menu option in a case management GUI, or as the begin- 
nings of a Balance WorkLoad process, where managers ^0 
multi-select from the list of found cases and reassign them 
or prompt them into the workflow (Uopend any FENDED 
items). 

Case Retrieval makes full use of the BLErrorLog, 
CNativeErrorLog, BLStatLog, BLDebugLog, 65 
CNativeDebugtog, BLDBConnMgr, BLProgramSecurity, 
BLCaseSession and BLCase objects. The majority of the 
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code is preferably implemented in a COM object to aUow 
other programs to include Case Retrieval capabilities within 
their operations. 

As discussed above, a letter generation wizard is prefer- 
ably included to provide a graphical user interface that steps 
a user through the creation of a custom letter. It is usually 
called from a Case Manager process that is customized for 
each client. The letter generation wizard interfaces with a 
word processing program in the conventional platforms 20, 
such as Microsoft Word. It allows the user to select from a 
list of letter templates. Once a letter template is selected, the 
wizard reads the template in, e.g., Microsoft Word, for each 
bookmark and displays the bookmarks in a window for the 
user to fill in. The wizard replaces the bookmark values with 
the provided values and sizes the fields according to user 
defined size configurations for each field. Macros within the 
template allow the user to finish the letter and return to the 
Case Manager process. After the Case Manager process, the 
work object is sent to the Draft Letter Committal back- 
ground process which commits the letter to the imaging 
system and adds the letter to the case folder. 

Illustrated in FIG. 5 is an example of how the Events 
Processor and Queue Assignment modules operate. When an 
event is detected, as indicated by Event Trigger 120, the 
Events Processor determines how the work item(s) 122 
associated with the event should be started through the 
workflow and what data to start in the workflow. The 
workflow dictates the work step 124. The Queue Assignment 
module then determines to which work division 126 the 
work item(s) 122 should be assigned. The configuration 
tables are used by the Events Processor and Queue Assign- 
ment modules to perform these tasks. 

One example of tables that could be used in the present 
invention is provided below. This is merely one example of 
many possible ways that tables could be used to minimize 
the extent that programs have to be modified during system 
implementation. 

The Case table (BL CASE) is the main processing table. 
It stores a record for each case per work type in the system. 
It is accessed by BLCase 64. There can be multiple case 
tables in the system. The table structure is always modified 
for each system implementation. Below is one example. 



BL_CASE 
( 



50 



) 



SCASEID 


VARCHAR2(16) 


not null, 


SWORKTYPE 


VARCHAR2(16) 


not null, 


SSTATUS 


VARCHAR2(16) 


not null, 


SOWNERID 


VARCHAR2(16) 


null, 


DCREATED 


DATE 


not null, 


SLASTUPDATEUSERID 


VARCHAR2(16) 


null. 


DLASTUPDATED 


DATE 


null, 


SACCOUNTNUM 


VARCHAR2(32) 


null, 



The Case Event table (BL_CASEEVENT) stores all the 
received and pending events associated with cases. It is 
written to and read from by BLCase Events 92. 



BL_CASEEVENT 

( 

SWORKTYPE 
SCASEID 

SEVE^^^ooDE 

SEVENTSTATE 
SEVENTDESC 



VARCHAR2(16) not null, 

VARCHAR2(16) not null, 

VARCHAR2(32) not null, 

CHAR(1) not null, 

VARCHAR2(256) not null. 



08/26/2003, EAST Version: 1.04.0000 



13 



US 6,606,740 Bl 



14 



-continued 



DEXPIRE 


DATE 


null. 




BU_CASERELAnONSHIP 








SGROUPID 


VARCHAR2(16) 


null. 




( 










SGROUPEVENTCODE 


VARCHAR2C32) 


null. 


5 




SCfflUX:ASE[D 


VARCHAR2(16) 


DOC 


null. 


SPROCESSINGSTATUS 


CHAR(l) 


not null. 






SCHtLDWORKTYPE 


VARCHAR2(16) 


not 


null, 


DRECEIVED 


DATE 


null. 






SPARENTCASEID 


VARCHAR2(16) 


not 


null, 


SCASEITEMNAME 


VARCHAR2(64) 


null. 






SPARENTWORKTYPE 


VARCHAR2(16) 


not 


null, 


SOPTIONALEVENTDATA 


VARCHAR2(128) 


null. 






DCREATED 


DATE 


not 


null, 


DCREATED 


DATE 


not DuU, 




) 
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The Case Item table (BL_CASEITEM) stores the refer- 
ence to the items associated with cases. For example, the 
reference number for documents associated with cases arc 
stored in the table. BLCaseltems 96 accesses the table. 



15 



The Case Audit Session table (BL„ 
CASEAUDITSESSION) is the parent table for aU audits 
during a case session. It is accessed by BLCaseAuditSession 
110. 



BL_CASEITEM 



20 



SCASEID 

SWORKTYPE 

SITEMNAME 

SrrEMDISPLAYNAME 

nTEMTYFE 

DCREATED 

) 



VARCHAR2C16) 

VARCHAR2(16) 

VARCHAR2C64) 

VARCEIAR2(12S) 

NUMBER(4) 

DATE 



not null, 
not null, 
not null, 
null, 
not null, 
not null, 



The Draft Case Item table (BL_DRAFTCASEITEM) 
stores the draft items and data associated with cases. For 
example, the binary draft documents associated with cases 
are stored in the table. BLDraftCaseltems 100 accesses the 
table. 



BI^DRAFTCASEITEM 
( 

SCASEID 

SWORKTYPE 

SDRAFTTTEMNAME 

SDRAFTTTEMDISPLAYNAME 

SDOCUMENTCLASS 

SDRAFTTTEMTYFE 

SINDEXVALUES 

BFTEMDATA 

DCREATED 



VARCHAR2(16) 

VARCHAR2(16) 

VARCHAR2(64) 

VARCHAR2(128) 

VARCHAR2C32) 

VARCEIAR2(64) 

VARCHAR2C2000) 

LONG RAW 

DATE 



not null, 
not null, 
not null, 
null, 
not null, 
not null, 
null, 
null, 
not null. 



30 



The Case Lock table (BL_CASELOCK) stores the cases 
that are currently locked for processing by any program 50 
module. BLCaseSession 60 creates and deletes the case lock 
records. 



BU_CASEAUDrrSESSION 

( 

SWORKTYPE 

SCASEID 

SSESStONID 

DCREATED 

SUSERID 



VARCHAR2(16) 
VARCHAR2(1^ 
VARCHAR2(16) 
DATE 

VARCHAR2(16) 



not null, 
not null, 
not null, 
not null, 
not null. 
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The Scan Productivity table (BL_ 
SCANPRODUCnVITY) is a processing table-used to store 
the statistics to run a productivity report for scan operators. 
The table records are written by the Scan interface 
(described below) and are not modified by any other process. 



Bl^SCANPRODUCnvrrY 



35 



SBATCHNAME 


VARCHAR2(1S) 


null. 


BBATCHACCEPTED 


CHAR(l) 


null. 


SUSERID 


VARCHAR2(8) 


null. 


DRECEIVEDDATE 


DATE 


null. 


lEXFECTEDCOUNT 


NUMBER(3) 


null. 


lACTUALCOUNTT 


NUMBER(3) 


null. 


IPAGECOUNT 


NUMBER(3) 


null. 


SDOCTYPE 


VARCHAR2(20) 


null. 


DSCANSTARTTIME 


DATE 


null. 


DSCANSTOPITME 


DATE 


null. 



) 



45 



The Index Productivity table (BL_ 
INDEXPRODUCnVITY) is a processing table used to 
store the statistics to run a productivity report for index 
operators. The table records are written by the Index inter- 
face (described below) and are not modified by any other 
process, but are used for reporting purposes. 



BL_CASELOCK 

( 

sCAsao 

SWORKTYPE 

SUSERID 

DLOCKED 



VARCHAR2 (16) not null, 

VARCHAR2 (16) not null, 

VARCHAR2 (16) not null, 

DATE not null. 
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The Case Relationship table (BL_ 
CASERELAnONSHIP) stores the relationship between 
cases. It is accessed by the BLCase object using the Get- 
Children and GetParent methods. 



BI^tNDEXPRODUCnvrrY 

( 

SBATCHNAME 
SUSERID 

[DOCUMENTCOUNT 

[NUMBER INDEXED 

[NUMBERRESCANNED 

INUMBERADDED 

INUMBERDELETED 

DSTARTRME 

DSTDPTIME 



VARCHAR2(18) 

VARCHAR2(8) 

NUMBER(3) 

NUMBER(3) 

NUMBER(3) 

NrUMBER(3) 

NUMBER(3) 

DATE 

DATE 



null, 
null, 
null 
null, 
null, 
null, 
null, 
null, 
null. 



The Rescan table (BL RESCAN) is a processing table that 
stores documents that need to be rescanned. The table 
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records are written by the Index interface and are not 

modified by any other process. -continued 



BL^RESCAN 

( 



SDoao 


VARCHAR2 (8) 


aull . 


SBATCHNAME 


VARCEIAR2 (18) 


QUii , 


SUSERID 


VARCHAR2 (8) 


flUll, 


INUMBERPAGES 


NUMBER (3) 


aull , 


SPAGEPOSmON 


VARCHAR2 (25) 


aull, 


SDOCTYFE 


VARCHAR2 (20) 


aull . 


DRESCANTIME 


DATE 


aull 



) 



The Document Type table (BL_DOCTYPE) stores the 
valid business document types and their associated scan 
settings. This table is accessed by the Scan and Index 
graphical user interfaces. The Scan and Index interfaces use 
the table to provide a Ust of valid document types to the user. 
Once a valid document type is chosen, the Scan program 
looks up the associated settings and template to which to 
attach the scan batch. This table can be modified by business 
users through the System Maintenance interface (described 
below). 



BL_DOCTYPE 
( 

SDOCTYPE VARCHAR2 (20) not null , 

SSETHNGS VARCHAR2(20) not null , 

STEMPLATE VARCHAR2 (20) null 

) 



The Case Audit Detail table (BL_ 
CASEAUDITDETAIL) stores audit records created for each 
case. It is accessed by BLCaseAudit 114. 



BU-CASEAUDrrOETAIL 

( 



SSESSIOMD 


VARCHAR2(16) 


act null. 


DCREATED 


DATE 


act null. 


SCATEGQRY 


VARCHAR2C16) 


not null. 


SACnON 


VARCHAR2(16) 


not null. 


SDESCRIFnON 


VARCHAR2(512) 


null. 


SAUDirDETAILl 


VARCHAR2C64) 


null. 


SAUDITDErAIL2 


VARCHAR2(64) 


null. 


SAUDITDCTAIL3 


VARCHAR2(64) 


null. 



A set of baseline tables need to be configured for each 
implementation of the present invention. Each system 
implementation builds upon this framework to add its own 
tables. The baseline tables that need to be configured are: 



BL_BOOKMARKMAP 

BL_DOCTYPEMAP 

BL_UPDAreORDER 

BU_SYSTEMPARAM 

Bl^EVENTPROCFlELDMAP 

Rl. I KI I KR 
BL_LEITERGROUP 



10 

In addition, there will almost always be a set of business 
specific tables at each site. 

The User Profile tabic (BL_USERPROFILE) is a refer- 
ence table that stores all the users in the system and their 
associated characteristics. The User Distribution process 
15 accesses the User Profile table to determine whether a user 
is available to receive work. 



on Bl^USERPROFILE 
( 

SUSERID VARCHAR2 (8) not null, 
SUSERNAME VARCHAR2 (64) not null, 
BISAVAILABLE CHAR (1) not null, 
) 

25 

The Program Security table (BL_ 
PROGRAMSECURITY) stores the first level of security, 
the program module level. BLProgramSecurity 76 accesses 
the table. The table records are maintained by business users 
through the System Maintenance interface. 



Bl^PROGRAMSECURIXy 

( 

SUSERID VARCHAR2 (8) not null, 

SPROGRAMNAME VARCHAR2 (16) not null. 



The Task Security table (BL_TASKSECURITY) stores 
the second level of security, the task level. BLProgramSe- 
curity 76 accesses the table. The table records are main- 
tained by business users through the System Maintenance 
interface. 



45 BU-TASKSECURTTY 
( 

SUSERID VARCHAR2 (8) not null, 

SPROGRAMNAME VARCHAR2 (16) not null, 
STASKNAME VARCHAR2 (16) not null, 

) 

50 

The Function Security table (BL„ 
FUNCTIONSECURITY) stores the third level of security, 
the function level. BLProgramSecurity 76 accesses the table. 
The table records are maintained by business users through 
55 the System Maintenance interface. 



BL_USERPROFILE 

BL_PROGRAMSECURrrY 

BL_TASKSECURITY 

BL_FUNCnONSECURrrY 

BL_USERWORKLOAD 

BL_USERWORKSTEP 

BL_USERWORKSTEPDIVISION 

BL_WORKTyPE 

BL_WORKSTEP 

BU_WORKSrrEPDIVISION 

BU_WORKSTtPRULE 

BI^BOOKMARKCONFIG 



60 



65 



BU_FUNCnONSECURITY 
( 

SUSERID 

SPROGRAMNAH^ 

STASKNAME 

SFUNCnONNAME 



VARCHAR2(8) not null, 

VARCHAR2(16) not null, 

VARCHAR2(16) not null, 

VARCHAR2(16) not null, 



The User Work Load table (BL_USERWORKLOAD) 
stores the relative load that each user should be assigned 
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Bl^USERWORKLOAD 
( 



SUSERID 

SWORKTYPE 

ILOADFACTOR 



VARCHAR2 (8) 
VARCHAR2 
NUNBER (4) 



not null, 
cot null, 
not null. 
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during the User DislributioQ process. The records in the 
table are maintained by business users through the System 
Maintenance interface. 



BU_WORKSTEP 

( 



SWORKTYPE 


VARCHAR2(16) 


Dot null, 


SWORKSTEP 


VARCHAR2(16) 


Dot null, 


SWCRKSTTEPNAME 


VARCHAR2(64) 


DOt null, 


BISSYSTTEMSTEP 


CHAR(l) 


Dot null, 


BISFnXERED 


CHAR(l) 


not null, 


BISEVENTALLOWED 


CHAR(l) 


not null, 


SWORKFLOWPERFORMERNAME 


VARCHAR2(64) 


null. 


SEVENTACnONCODE 


CHAR(l) 


null, 



The User Work Step table (BL_USERWORKSTEP) 
defines the work steps that a msci is allowed to access. 



Bl^USERWORKSTEF 
( 

SUSERID 

SWORKTYPE 

SWORKSTEP 



VARCHAR2 (8) 
VARCHAR2 (16) 
VARCHAR2 (1^ 



not null, 
not null, 
not null. 



BL_USERWORKSTEPDIVISION 
( 

SUSERID 

SWORKTYPE 

SWORKST1EP 

SWORKSTEPDIV 

IWORKSTEPDIVPRIORnr 

) 



VARCHAR2(8) 

VARCHAR2(16) 

VARCHAR2(16) 

VARCHAR2(16) 

NUMBER(2) 



not null, 
not null, 
not null, 
not null, 
not null. 



The Work Type table (BL_WORKTYPE) stores each 
different type of work in the system. A work type is defined 
as the data and processes associated with work. The param- 
eters associated with each work type describe the database 
table and the workflow engine class that should be accessed 
for processing. Work Types are associated with a specific 
BLCase Table and the system can support multiple Work 
Types. 



BU_WORKTYPE 
( 

SWORKTYPE 

SWORKTYPENAME 

SCASETABLENAME 

SWORKFLOWCLASS 

BPROCESSMUUTPl-EEVENTS 



VARCHAR2(16) not null, 

VARCHAR2(64) not null, 

VARCHAR2(64) not null, 

VARCHAR2(64) null, 

CHAR(l) null, 



The Work Step table (BL_WORKSTEP) stores all the 
work steps associated with a work type. The work steps must 
also correspond to the workflow engine process map. There 
are characteristics about work steps that are captwed in this 
table. The table is configured initially during system imple- 
mentation. It is not changed often during the life of the 
system. 



The Work Step Division table (BL_ 
WORKSTEPDIVISION) stores the work step divisions 
associated with each work type and work step combination. 
Work Step Divisions are segmentations of Work Steps that 
provide work specialization. The records are maintained by 
business users through the System Maintenance interface. 
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The User Work Step Division table (BL_ 
USERWORKSTEPDIVISION) stores the order of work 
step divisions in which a user receives work. BLCaseSes- 
sion 60 accesses this table using the GetUserWorkList 
method. 
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BL_WORKSTEPDIVISION 
( 

SWORKTYPE 

SWORKSTEP 

SSWWORKSTEPDIV 

SWORKSTEPDIVNAME 

IWORKSTEPDIVTYPE 

BISDEFAUIT 



) 



VARCHAR2(16) 

VARCHAR2(16) 

VARCHAR2(16) 

VARCHAR2(64) 

NUMBER(l) 

CHAR(l) 



not null, 
not null, 
not null, 
not null, 
not null, 
not cull. 
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The Work Step Rule table (BL_WORKSTEPRULE) 
stores the rules associated with work step divisions. The 
rules are prioritized to read and determine to which work 
step division a case should be assigned. These rules may be 
maintained by business users through the System Mainte- 
nance interface. 



BL_WORKSTEPRULE 
( 

SWORKTYPE 
SWORKSTEP 
IWORKSTEPRULEP^UM 
SWORKSTEPRULE 
SNEWWORKSTEPOrV 
45 BDISABLED 
) 



VARCHAR2(16) 

VARCHAR2(15) 

NUMBER(4) 

VARCHAR2(2000) 

VARCHAR2(1(S) 

CHARCl) 



not null, 
not null, 
not null, 
not null, 
not null, 
not null, 



The Book Mark Configuration table (BL_ 
BOOKMARKCONFIG) stores the height and width of each 
50 letter field. It is accessed by the Letter Generation Wizard to 
size each bookmarked field when presenting the data entry 
screen to a user. This table is optional and is managed by 
business users through the System Maintenance interface. 



55 



Bl^BOOKMARKCONFIG 



60 



SBOOKMARKNAME 

IHEIGHT 

IWIDTH 



) 



VARCHAR2(64) not null, 
NUMBER(2) null, 
NUMBER(2) null. 



The Book Mark Map table (BL_BOOKMARKMAP) 
stores the association between a letter bookmark and the 
65 case field that should be assigned to it. The Letter Generation 
Wizard uses the table to query by the bookmark name and 
replace the bookmark with the specified case field value. 
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BI^BOOKMARKMAP 
( 

SBOOKMARK 
SWORKTYPE 
SRELDNAME 
IFIELDTYPE 

) 



VARCHAR2 (64) 
VARCHAR2 (16) 
VARCHAR2 (64) 
NUMBER (2) 
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not null, 
not null, 
not null, 
not null. 



The Doc Type Map table (BL_DOCTYPEMAP) maps an 
incoming document type to a work type. This table is 
accessed by the Case Builder process. 



20 



They are associated with the Letter Group table. The Letter 
Generation Wizard accesses the table to retrieve all the letter 
templates into a list given a letter group. The table is 
maintained by business users through the System Mainte- 
nance interface. 



10 



BL_ 
( 



) 



.LETTER 

SGROUPtD 
SLETTERID 

SUETTERDISPIAYNAME 

SLETTERnLENAME 

IDISPLAYORDER 



VARCHAR2(15) 

VARCHAR2(16) 

VARCHAR2(12S) 

VARCHAR2(32) 

NUMBER(4) 



not null, 
not null, 
not null, 
not null, 
not null, 



BUOCTYPEMAP 



SDOCTYPE 
SWORKTYPE 



) 



VARCHAR2 (16) 
VARCHAR2 (Ifi) 



not null, 
not null. 
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The Update Order table (BL_UPDArEORDER) dictates 
the order in which tables should be updated for a transaction. 
DBConnMgr 66 accesses this table to commit records in the 
correct order. This table is configured during system imple- 
mentation and is not changed very often during the life of the 
system. It is modified by a knowledgeable system adminis- 
trator or programmer. 



BU-UPDATEORDER 
( 



lORDER 
STABUENAME 



) 



NUMBER 
VARCHAR2 (64) 



not null, 
not null. 



The System Parameter table (BL_SYSTEMPARAM) 
stores system wide parameters. It is accessed by each 
program module. 



BU_SYSTEMPARAM 



SPARAMNAME 
SPRAMVALUE 



) 



VARCHAR2 (32) 
VARCHAR2 (256) 



not null 
null 



VARCHAR2(64) 
NUMBER(2) 
VARCHAR2C64) 
VARCHAR2(16) 



not null, 
not null, 
not null, 
not null. 



The Letter table (BL_LETTER) stores all the letter 
templates in the system and their associated characteristics. 



The Letter Group table (BL„LETTERGROUP) stores 
the list of letter templates grouped in business groups. The 
Letter Generation Wizard reads this table to display the list 
of valid tables for the user to select from. The Letter Group 
table is maintained by business users through the System 
Maintenance interface. 



BL^LETTERGROUP 
( 

SGROUPID 

SGROUPDISPLAYNAME 
IDISPLAYORDER 



) 



The Event Process Field Map table (BL_ 
EVENTPROCFIELDMAP) stores the work object fields 
that are created when a work object is injected into the 
workflow engine. There are different mappings for each 
work type. The table provides a configurable method to map 
fields to the work object before it is injected into the 
workflow. This is determined at each system implementation 
without needing to modify code. It is accessed by the Event 
Processor module. 



BL_EVENTPROCFIELDMAP 
( 

SFTELDNAME 
IFIELDTYPE 

SWORKTTEMFIELDNAME 
SWORKTYPE 



VARCHAR2(15) not null, 

VARCHAR2(128) not null, 
NUMBER(4) not null. 
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An example of workflow processing in a workflow pro- 
cessing system according to the present invention is illus- 
trated in FIG. 6. During system implementation, the base 
workflow process flow is defined in the workflow platform 

35 in the conventional platforms 20 using a workflow engine 
like FileNET Visual WorkFlo. Data Capture 130 may be a 
conventional process that places information to be used in 
electronic form. Imaging of documents, input of data from 
a database, input of transactional data, etc. are included. The 

40 Case Builder 132 organizes the information according to 
rules in the workflow platform in the conventional platforms 
20 and stores links to the data in conventional databases, 
data warehouses, etc. where the information is stored in the 
conventional platforms 20 by Data Capture 130. The Events 

45 Processor 134 is initially executed to place the new case in 
the first work step 124. The Queue Assignment module 136 
is then executed to place the case in the appropriate work 
queue or work step division, as discussed above with respect 
to FIG. 5. If the work step division requires 138 a case to be 

50 "owned" by a user, the user distribution module 140 is 
executed to assign ownership. Regardless of whether the 
case has been assigned to a particular user, Case Manager 
142 could be executed next. Case Manager 142 is uniquely 
created for each system implementation. Case Manager 142 

55 may be created using development tools such as Visual 
Basic or Visual C++. The case objects described with 
reference to FIGS. 4A-4C are used to quickly develop the 
code for Case Manager 142. 

If a letter is created in step 144, BLCase creates a new 

60 BLDraftCaseltem object 102. If it is desirable to convert the 
letter to TIFF format before committal to permanent storage 
on, e.g., an optical disk, the draft case item is sent to the 
Draft Committal process 146 for conversion of the letter to 
TIFF format and storage on, e.g., the optical disk. This 

65 process also changes the draft case item to a regular case 
item. Processing then continues as defined for the ^ecific 
business application in the workflow, engine and therefore, 
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the specific processing is not illustrated in FIG. 6. Typically, 
the object is suspended for additional information, destroyed 
because the case is done, or routed to another user. 

Preferably, at various times during work on a case, a 
check is made 148 to determine whether the case should be 5 
sent to Quality Assurance. If so, the Queue Assignment 
module 150 is called to place the case in a work division 126 
for case quality assurance review 152. 

As illustrated in FIG. 7, the present invention can be 
implemented on a conventional general purpose computer lO 
system, including a processor 202, memory unit 204 and 
input/output unit 206. When implemented on an enterprise 
basis, there will likely be a plurality of processors, memory 
units and very many input/output imits, such as desktop or 
notebook computers (not shown). These devices are likely to 15 
be networked, possibly using multiple network protocols. 
Any suitable conventional hardware and software can be 
used to provide the computer system, including distributed 
processing, intranets, personal computers, etc. 

The present invention has been described with respect to 20 
exemplary embodiments of a workflow processing 
framework, workflow development system and workflow 
processing system. 

However, the invention is not limited to these specific 
embodiments, but encompasses all of the subject matter of 25 
the following claims. 

The many feamres and advantages of the invention are 
apparent from the detailed specification and, thus, it is 
intended by the appended claims to cover all such features 
and advantages of the invention which-fall within the true 30 
spirit and scope of the invention. Further, since nimierous 
modifications and changes will readily occur to those skilled 
in the art, it is not desired to limit the invention to the exact 
construction and operation illustrated and described, and 
accordingly all suitable modifications and equivalents may 35 
be resorted to, falling within the scope of the invention. 

Reference Number list 



Conventional platforms 
Foundation objects 
Common objects 
Business processes 
BLCaseSession 
BLCaseWorkUst 
BLCase 

BU:)BConnMgr 

BLConfigParam 

BLDebugLog 

BLErrorLx)g 

BLStatLog 

BLProgramSecurity 

BLCorelnstMgr 

BLWFWorkListFields 

BLWFWorkListField 

VWOWorkQucry 

BLCaseFields 

BLWFWorkltemFields 

BLCaseEvents 

BLCaseltems 

BLCaseltem 

BLCase AuditSessio n 

BLDraftCaseltem 



40 



45 



50 



55 



60 
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BLDraftCaseFields 

BLCascAuditSessions 

BLCaseAuditSession 

BLCaseAudits 

BLCaseAudit 

ADODB RecordSet 

Event Trigger 

Work item(s) 

Work step 

Work division 

Data Capture 

Case Builder 

Events Processor 

Queue Assignment 

Assign User? 

User Distribution 

Case Manager 

Letter Created? 

Draft Committal 

Send for Quality Assurance? 

Queue Assignment 

Case Quality Assurance 

Processor 

Memory 

Input/Output 

What is claimed is: 

1. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database management system, accessed by a subset of 
the software objects, defining work taxonomy and work 
steps for workflow processing, said system comprising: 
a first database, accessed by the subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow 
processing, and 
a second database, accessed by the subset of the soft- 
ware objects via the database management system, 
storing case information within the workflow pro- 
cessing framework; and 
a workflow engine utilized by said set of software objects 
and the subset of the software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database management system to 
perform case processing, said workflow processing 
framework defining work step divisions for at least one 
of the work steps, wherein the work step divisions 
correspond to component processes defined by work 
step rules, and the work step divisions for the at least 
one of the work steps are prioritized when presented to 
a user. 

2. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database, accessed by a subset of said software objects, 
defining work taxonomy and work steps for workflow 
processing; and 
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a workflow engine used by said set of software objects 
and the subset of said software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database to perform case 
processing, said workflow processing framework 
defining work step divisions for at least one of the work 
steps, the work step divisions segregating work respon- 
sive to work characteristics analyzed according to work 
step rules, wherein the work step divisions correspond 
to component processes defined by the work step rules, 
and the work step divisions for the at least one of the 
work steps are prioritized when presented to a user. 

3. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business 
ftinctions, wherein said software objects comprise com- 
mon objects that are implementation independent and 
foundation objects; 
a database management system, accessed by a subset of 
the software objects, defining work taxonomy and work 
steps for workflow processing, said system comprising: 
a first database, accessed by the subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow 
processing, and 
a second database, accessed by the subset of the soft- 
ware objects via the database management system, 
storing case information within the workflow pro- 
cessing framework; and 
a workflow engine utilized by said set of software objects 
and the subset of the software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database management system to 
perform case processing, said workflow processing 
framework defining work step divisions for at least one 
of the work steps, wherein the foundation objects 
provide communication between the common objects 
and said workflow engine, the work step divisions 
correspond to component processes defined by work 
step rules, and the work step divisions for the at least 
one of the work steps are prioritized when presented to 
a user. 

4. The workflow processing fi-amework as recited in claim 

3, further comprising business processes customizable for 
each implementation. 

5. The workflow processing firamework as recited in claim 

4, wherein said business processes comprise at least one 
rules processor for building cases, responding to events and 
assigning work to specific work step divisions. 

6. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database management system, accessed by a subset of 
the software objects, defining work taxonomy and work 
steps for workflow processing, said system comprising: 
a first database, accessed by the subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow 
processing, and 
a second database, accessed by the subset of the soft- 
ware objects via the database management system. 
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Storing case information within the workflow pro- 
cessing firamework; and 
a workflow engine utilized by said set of software objects 
and the subset of the software objects using the work 
5 taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database management system to 
perform case processing, wherein said first database 
and said workflow engine are accessed by the subset of 
said software objects to generate a prioritized worklist 
each time a new session is started by a user, and where 
the subset of said software objects used to generate the 
prioritized worklist can invoke a prefetch object utiliz- 
ing program code to perform a prefetch operation 
having an enumerated type to determine components of 
the case information to be. prefetched from said second 
database and not specifying in the program code of the 
prefetch object what format of data is involved in the 
prefetch operation, said workflow processing frame- 
work defining work step divisions for at least one of the 
20 work steps, where the work step divisions for the at 
least one of the work steps are prioritized, 

7. The workflow processing framework as recited in claim 
1, wherein said database management system further com- 
prises \iser-definable tables to define at least one work queue 

25 and determine contents of work items in the at least one 
work queue. 

8. The workflow processing framework as recited in claim 
7, wherein said software objects comprise a queue assign- 
ment module to access the user-definable tables when a work 
item is received and to add the work item to at least one work 
step division based on business rules defined. 

9. The workflow processing framework as recited in claim 
1, wherein the subset of said software objects are used to 
retrieve a prioritized worklist comprising a prefetch object 
comprising program code to perform a prefetch operation 
based on information in said database and not specifying in 
the program code of the prefetch object what format of data 
is involved in the prefetch operation. 

10. The workflow processing framework as recited in 
^ claim 1, wherein the corresponding business functions of 

said software objects are linked in a parent-child relationship 
to provide easy navigation of business data hierarchy. 

11. The workflow processing framework as recited in 
claim 1, wherein said database frirther defines relationships 
between cases and business events. 

12. A method of developing a workflow processing 
system, comprising: 

providing a set of software objects, each uniquely per- 
forming a corresponding function in the workflow 
5Q processing system, and a set of process definitions, 
accessed by a subset of the software objects; 
providing a database management system, comprising: 
a first database, accessed by a subset of the software 
objects via the database management system, defin- 
55 ing work type and work steps for workflow process- 

ing; and 

a second database, accessed by the software objects via 
the database management system, storing case infor- 
mation within the workflow processing system; 

60 utilizing a workflow engine to modify the process defi- 
nitions which correspond to work types and work steps 
for workflow processing, wherein the workflow engine 
is utilized by said workflow processing system in 
combination with said database management system to 

65 perform case processing; and 

defining work step divisions using the workflow process- 
ing system for at least one of the work steps, wherein 
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the work step divisioos correspond to component pro- 
cesses defined by work step rules, the work step divi- 
sions for the at least one of the work steps are priori- 
tized when presented to a user, and the workflow 
processing systeca is supported by the workflow engine 
and the database management system. 

13. The method as recited in claim 12, wherein said 
providing of process definitions comprises providing tables, 
configurable by a user and accessible by a subset of the 
software objects unchanged during said generating of the 
workflow processing system, to define the work types, the 
work steps and work divisions of the work steps, and 

wherein said modifying comprises configuring the tables 
accessed by the subset of the software objected 
unchanged during said generating. 

14. The method as recited in claim 13, wherein the tables 
comprise an event process field map table to pre-fill work 
object fields from case data defining a work type for each 
work object in the workflow processing system without 
modifying program code. 

15. The method as recited in claim 12, further comprising 
providing customizable user interfaces, separate from the 
software objects, to perform functions unique to the work- 
flow processing system produced by said generating. 

16. The method as recited in claim 15, further comprising 
providing at least one rules processor for assigning work. 

17. A computer system programmed to generate a work- 
flow processing system, comprising: 

a memory unit storing a set of software objects, each 
uniquely performing a corresponding function in the 
workflow processing system, and a set of process 
definitions, accessed by a subset of the software objects 
in a database management system, comprising: 
a first database, accessed by a subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow process- 
ing; and 

a second database, accessed by the software objects via 
tbe database management system, storing case infor- 
mation within flie workflow processing system; 

a processing unit, coupled to said memory unit, to execute 
the software objects utilizing a workflow engine and 
database management system accessing the process 
definitions, wherein the workflow engine is utilized by 
said workflow processing system in combination with 
said database management system to perform case 
processing; and 

at least one input/output unit, coupled to said memory imit 
and said processing unit, to enter data stored by said 
processing unit in the process definitions of said 
memory unit to define work types and work steps for 
workflow processing, said workflow processing system 
defining work step divisions for at least one of the work 
steps, wherein the work step divisions correspond to 
component processes defined by work step rules, and 
the work step divisions for the at least one of the work 
steps are prioritized when presented to a user. 

18. A workflow processing system, comprising: 

a memory unit storing a set of software objects, each 
uniquely performing a corresponding function in said 
workflow processing system, 
a database management system, comprising: 
a first database, accessed by a subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow 
processing, and 
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a second database, accessed by the software objects via 
the database management system, storing within said 
workflow processing system; 

at least one input/output unit, coupled to said memory 
unit, to enter and retrieve data stored in the first and 
second databases of said memory unit; and 

a processing unit, coupled to said memory unit and to said 
at least one input/output unit, to execute the software 
objects utflizing a workflow engine and the database 
management system and update the case information in 
the second database based on the work type and work 
steps in the first database, said workflow processing 
system defining work step divisions for at least one of 
the work steps, wherein the work step divisions corre- 
spond to component processes defined by work step 
rules, the work step divisions for the at least one of the 
work steps are prioritized when presented to a user, and 
said workflow engine is utilized by said workflow 
processing system in combination with said database 
management system to perform case processing. 

19. At least one computer program, embodied on a 
computer-readable medium, to create a workflow processing 
system, comprising: 

a set of software objects, each uniquely performing a 
corresponding function in the workflow processing 
system; 

a database management system, accessed by a subset of 
the software objeas, comprising: 
a first database, accessed by a subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow process- 
ing; and 

a second database, accessed by the software objects via 
the database management system, storing within said 
workflow processing system; 

a workflow engine defining a base workflow process flow 
utilized by said set of software objects and the subset of 
the software objects to perform the workflow 
processing, wherein said workflow engine is utilized by 
said workflow processing system in combination with 
said database management system to perform case 
processing; and 

select graphical user interface modules, said workflow 
processing system defining the work types and the 
work: steps that correspond to the base workflow 
process flow and defining work step divisions for at 
least one of the work steps, wherein the work step 
divisions conrespood to component processes defined 
by work step rules, and the work step divisions for the 
at least one of the work step r prioritized when pre- 
sented to a user. 

20. The at least one computer program as recited in claim 
19, wherein the subset of said software objects used to 
retrieve the prioritized worklist comprise a prefetch object 
comprising program code to perform a prefetch operation 
based on information in said database and not specifying in 
the program code of the prefetch object what format of data 
is involved in the prefetdi operation, 

21. The at least one computer program as recited in claim 
30, wherein the prefetch object is a multi-threaded object 
operating in a producer-consumer environment, using 
semaphores, threads, and class member variables to keep 
track of current and next case objects, comprising 

a consumer thread to obtain a current case object from a 
work list, and 

a producer thread, executing as long as the prefetch object 
exists in memory, to retrieve a next available case 
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object when the nexi case object is null and, when the 
next case object exists, to wait until the current case 
object is retrieved into processing by the consumer 
thread before retrieving the next available case object. 

22 . A workflow processing framework, scalable for use by 5 
single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database management system, accessed by a subset of 
the software objects, defining work taxonomy and work 
steps for workflow processing, said system comprising: 
a first database, accessed by the subset of the software 
objects via the database management system, defin- 
ing work type and work steps for workflow 
processing, and 
a second database, accessed by the subset of the soft- 
ware objects via the database management system, 
storing case information within said workflow pro- 
cessing framework; 
a workflow engine utilized by said set of software objects 
and the subset of the software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database management system to 
perform case processing, said workflow processing 
framework defining work step divisions for at least one 
of the work steps, the work step divisions segregating 
work responsive to work characteristics analyzed 
according to work step rules, wherein the work step 
divisions correspond to component processes defined 
by the work step rules, and the work step divisions for 
the at least one of the work steps are prioritized when 
presented to a user; and 
at least one rules processor building cases or processing 
existing cases by organizing data entered or stored in 
the second database, creating an event in response to 
the data, generating a work item in response to the 
event, and assigning work to place each of the cases in 40 
a work step division depending on a definition of a 
corresponding work step. 

23. A workflow processing framework, scalable for use by 
single department to an entire enterprise, comprising: 

a set of software objects, each imique throughout the 45 
enterprise, to support corresponding business func- 
tions; 

a database management system, accessed by a subset of 
the software objects, defining work taxonomy and work 
steps for workflow processing, said system comprising: 50 
a first database, accessed by the subset of the software 
objects via the database management system, defin- 
ing work types and work steps for workflow 
processing, 

a second database, accessed by the subset of the soft- 55 
ware objects via the database management system, 
storing case information within the workflow pro- 
cessing framework; and 
a workflow engine utilized by said set of software objects 
and the subset of the software objects using the work 
taxonomy to perform the workflow processing and 
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utilized by said workflow processing framework in 
combination with said database management system to 
perform case processing, said workflow processing 
framework defining work step divisions for at least one 
of the work steps, wherein the work step divisions 
correspond to component processes defined by work 
step rules and assigning a case to a work step division 
based on case data and the work step rules associated 
with the work step and assigning the case to a user 
based on work load computed using data in the second 
database and a work load factor in the first database 
when[]the work step division is a user type. 

24. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database, accessed by a subset of said software objects, 
defining work taxonomy and work steps for workflow 
processing; and 

a workflow engine used by said set of software objects 
and the subset of said software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database to perform case 
processing, said workflow processing framework 
defining work step divisions for at least one of the woric 
steps, the work step divisions segregating work respon- 
sive to work characteristics analyzed according to work 
step rules, wherein the work step divisions correspond 
to component processes defined by the work step rules, 
the work step divisions for the at least one of the work 
steps are prioritized when presented to a user, and said 
workflow processing framework enabling the user to 
define work steps without requiring coding changes to 
the subset of the software objects. 

25. A workflow processing framework, scalable for use by 
a single department to an entire enterprise, comprising: 

a set of software objects, each unique throughout the 
enterprise, to support corresponding business func- 
tions; 

a database, accessed by a subset of said software objects, 
defining work taxonomy and work steps for workflow 
processing; and 

a workflow engine used by said set of software objects 
and the subset of said software objects using the work 
taxonomy to perform the workflow processing and 
utilized by said workflow processing framework in 
combination with said database to perform case 
processing, said workflow processing framework 
defining work step divisions for at least one of the work 
steps, the work step divisions segregating work respon- 
sive to work characteristics analyzed according to woric 
step rules, wherein the work step divisions correspond 
to component processes defined by the work step rules, 
said workflow processing framework enabling a user to 
select from a list of cases and reassign at least one case 
from the list or prompt the at least one case into the 
workflow to balance a workload. 
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